See commit, based on top of
#36702

Postgres-style `age(a, b)` is annotated `is_monotone = "(true, true)"`,
but it is non-monotone in either argument.

First argument: the carry logic in the calendar-aware difference borrows
a whole month's worth of days when the day field goes negative, which
breaks the lex order of `Interval` (months, days, micros) at month
boundaries:

  age(2024-03-31, 2024-02-15) = {1 month, 16 days}
  age(2024-04-01, 2024-02-15) = {1 month, 15 days}   ← lex-smaller
  age(2024-05-01, 2024-02-15) = {2 months, 15 days}

Second argument: after the algorithm's final sign-revert, the same
day-borrow makes the result dip non-monotonically as `b` crosses a
month boundary:

  age(2024-02-29, 2024-03-30) = {-1 month, -1 day}
  age(2024-02-29, 2024-03-31) = {-1 month, -2 days}  ← lex-smaller
  age(2024-02-29, 2024-04-01) = {-1 month, -1 day}

Demotes both `age_timestamp` and `age_timestamp_tz` to
`(false, false)`. Adds regression tests in `interpret.rs` exercising
the abstract interpreter via a `>=` predicate, mirroring the existing
tests for the analogous `add_timestamp_interval` and
`date_bin_timestamp` bugs.

Same bug class as
5257b0d
and
51e86ed.

…36721)

### Motivation

Even with the monotonicity fixes in #36702 and #36708 (both merged),
workload-replay was still hitting `persist filter pushdown correctness
violation!`. The audit log on that failure (database-issues#9656,
`u103`) showed:

```
mfp = MapFilterProject {
  expressions: [CastStringToUuid(Column(3, "merchant_group_id"))],
  predicates:  [(2, Not(IsNull(Column(1, "checksum"))))],
  projection: [0, 1, 2, 4, 5, 6],
  input_arity: 6
}
upper_bounds: [cast_timestamp_tz_to_mz_timestamp(Coalesce(deleted_at, '9999-12-31'))]

stats: checksum lower="bar" upper="bar"; deleted_at = 2025-06-16 (single value)
result: Err((DataflowErrorSer(143), 1779629555000, +1))
```

The interpreter computed:
- predicate `NOT IsNull(checksum)` → `{True}` (stats say non-null).
- upper-bound check `2025-06-16 >= mz_now` → `{False}` (frontier was
past 2025-06-16).
- `AND({True}, {False}) = {False}`, `fallible = false`.

→ `may_keep=false, may_error=false, may_skip=true` → **Discard the
part**.

But the actual MFP runtime ran the predicate (True), then evaluated the
`cast_string_to_uuid("merchant_group_id_a")` expression (NOT a valid
UUID), which errored, and the whole row was emitted as `Err`. The
discarded part actually had an error row to emit.

### Description

This is a different bug class from the monotonicity fixes (#36702 /
#36708); it stands on its own. The runtime evaluator
(`SafeMfpPlan::evaluate_inner`) runs every MFP expression once all
preceding predicates pass; any expression error propagates as the row's
error result. The abstract interpreter's `mfp_filter` /
`mfp_plan_filter`, however, only ANDs together the predicates and
temporal bounds — so the AND result misses the fallibility of any
expression whose result column isn't referenced by a predicate or bound.

This PR overrides `mfp_filter` and `mfp_plan_filter` on `ColumnSpecs` to
set the returned summary's `fallible` bit if any of the MFP expressions'
specs are fallible. Conservative (we'll keep parts where a predicate
could-but-doesn't-have-to fail, even though predicate short-circuiting
would have prevented the expression from running) but sound and matches
the runtime semantics.

The default trait-level implementation (used by `Trace`) is unchanged,
since `Trace` is about pushdownability rather than soundness.

### Verification

- New regression test
`interpret::tests::test_mfp_unreferenced_fallible_expression`: builds an
MFP with one always-erroring expression
(`cast_string_to_uuid("not-a-uuid")`) and one always-passing predicate,
asserts that the interpreter's summary `may_fail()`. Fails on the
pre-fix code; passes on the fix.
- New proptest
`interpret::tests::test_mfp_filter_fallibility_equivalence`: for a
random expression placed unreferenced in
`MapFilterProject::expressions`, verifies that whenever runtime
evaluation on a row from the stats range errors, the interpreter's
summary reports `may_fail()` — directly checking the soundness claim
against the MFP impl.
- `cargo test -p mz-expr --lib` — all tests pass.
- Workload-replay should stop hitting the audit panic on this class of
MFP (cast/parse expression columns that aren't gated by a predicate).

### Cost

Any MFP with a fallible expression in its `expressions` list will now
keep parts that would previously have been discarded by temporal-bound
checks. The tighter version would only mark fallibility when the
predicates' spec admits `True` (so the expression would actually run at
runtime); that's a follow-up if the conservative version costs too much
in practice.

---------

Co-authored-by: Claude <noreply@anthropic.com>